Celestin Apprentice 5/Apprentice-Release5.iso/Information/CSMP Digest/volume 3/csmp-digest-v3-096

Text File | 1995-12-31 | 61KB | 1,623 lines

C.S.M.P. Digest             Wed, 03 May 95       Volume 3 : Issue 96

Today's Topics:

        Drawing with VBL interrupts?
        Is Delay() defunct?
        Looking for advice on a jGNEFilter...
        NEW DEVELOPMENT ARCHIVE at AMUG!
        Problem drawing PICT with QT (-8976!?)
        QuickTime & MPEG-Streams?
        Speeding up NewPtr
        Where is the QTv2.0 header file?
        [MINI FAQ] Programming with MacTCP
        [Q] Temporary Files
        [Q] Where is the stack?



The Comp.Sys.Mac.Programmer Digest is moderated by Francois Pottier
([e-mail]).

The digest is a collection of article threads from the internet newsgroup
comp.sys.mac.programmer.  It is designed for people who read c.s.m.p. semi-
regularly and want an archive of the discussions.  If you don't know what a
newsgroup is, you probably don't have access to it.  Ask your systems
administrator(s) for details.  If you don't have access to news, you may
still be able to post messages to the group by using a mail server like
anon.penet.fi (mail [e-mail] for more information).

Each issue of the digest contains one or more sets of articles (called
threads), with each set corresponding to a 'discussion' of a particular
subject.  The articles are not edited; all articles included in this digest
are in their original posted form (as received by our news server at
nef.ens.fr).  Article threads are not added to the digest until the last
article added to the thread is at least two weeks old (this is to ensure that
the thread is dead before adding it to the digest).  Article threads that
consist of only one message are generally not included in the digest.

The digest is officially distributed by two means, by email and ftp.

If you want to receive the digest by mail, send email to [e-mail]
with no subject and one of the following commands as body:
    help                                Sends you a summary of commands
    subscribe csmp-digest Your Name     Adds you to the mailing list
    signoff csmp-digest                 Removes you from the list
Once you have subscribed, you will automatically receive each new
issue as it is created.

The official ftp info is //ftp.dartmouth.edu/pub/csmp-digest.
Questions related to the ftp site should be directed to
[e-mail].

-------------------------------------------------------

>From [e-mail] (Eric L. Singer)
Subject: Drawing with VBL interrupts?
Date: 9 Apr 1995 20:30:15 GMT
Organization: New York University


I am trying to do pict drawing using the vertical refresh interrupt (VBL)
to eliminate screen flicker during animation.

I had originally tried building a queue of info for CopyBits requests and
then drawing them during the VBL interrupt by dequeuing the info and
calling CopyBits for each request.

The problem is that CopyBits can call the memory manager and move memory
- a no-no during interrupt processing.

Can anyone suggest a better way to do this?

Thanks,
Eric Singer



+++++++++++++++++++++++++++

>From Ed Wynne <[e-mail]>
Date: 11 Apr 1995 17:52:43 GMT
Organization: The University of Michigan

In article <[e-mail]> Florian -FDj- Dejako,
[e-mail] writes:
>Don't do QuickDraw stuff during VBLs. In general, synching animations by
>VBL tasks isn't a good idea at all. QuickTime doesn't do it, and it
>doesn't flicker. You shouldn't do it either. Better avoid redrawing areas
>on the screen twice etc... There are a couple of tricks that can help you
>avoid flicker.
>

QuickTime doesn't do it, and it doesn't flicker...it tears...quite
noticeably
sometimes.  There is absolutely nothing wrong with syncing animations to a
VBL interval, the no-no is drawing at interrupt time.  Instead you should
use
a VBL task to set a global whenever the VBL interval hits.  (Make sure
your
using SlotVInstall to get the VBL you think your getting...)  Your main
drawing
loop should be waiting for this global to change, and when it does it
should
then start redrawing...at non-interrupt time.

-ed

+++++++++++++++++++++++++++

>From Hiep Dam <[e-mail]>
Date: Wed, 12 Apr 95 03:02:10 -0500
Organization: Delphi ([e-mail] email, 800-695-4005 voice)

Eric L. Singer <[e-mail]> writes:

>I am trying to do pict drawing using the vertical refresh interrupt (VBL)
>to eliminate screen flicker during animation.

Well, you shouldn't call CopyBits (as you said). I believe the normal way is
to set a flag in your interrupt, and have a loop somewhere to check for this
flag. If it's set, then call your CopyBits routine (and don't forget to reset
your flag after CopyBitsing) from this loop. Voila!

As an aside, IMHO you shouldn't use VBL interrupts to do animations. Use the
Time Manager instead; different monitors have different refresh rates, so
you might end up with different animation rates on different monitors, not to
mention using the VBL is more likely to become "sticky"...

Did I mention GWorlds? That and the Time manager should suit you fine...

--Hiep

+++++++++++++++++++++++++++

>From [e-mail] (Sherman Uitzetter)
Date: Wed, 12 Apr 1995 16:46:22 +0100
Organization: University of Pittsburgh


In article <[e-mail]>, Hiep Dam <[e-mail]> wrote:
> As an aside, IMHO you shouldn't use VBL interrupts to do animations. Use the
> Time Manager instead; different monitors have different refresh rates, so
> you might end up with different animation rates on different monitors, not to
> mention using the VBL is more likely to become "sticky"...

Actually (I believe) VBL interrupts on the Mac occur when the electron beam
is moving from the bottom to the top of the screen on which the interrupt was
"installed".  That is, they ARE synch'd to the refresh rate of the monitor
you install the interrupt to (via SlotVInstall()).

If you want to get every ounce of drawing time you can before the next
retrace, use a VBL interrupt AND the Time Manager to wait for the beam to
get just past the area of the screen you're drawing in ;-) (this may not
buy you
too much extra drawing time but it is neat).

Hope that made sense,
-Sherman.

+++++++++++++++++++++++++++

>From [e-mail] (AFC JLloyd)
Date: 12 Apr 1995 21:58:41 -0400
Organization: America Online, Inc. (1-800-827-6364)

>In article <[e-mail]>, Hiep Dam <[e-mail]>
wrote:
>> As an aside, IMHO you shouldn't use VBL interrupts to do animations.
Use the
>> Time Manager instead; different monitors have different refresh rates,
so
>> you might end up with different animation rates on different monitors,
not to
>> mention using the VBL is more likely to become "sticky"...
>
>Actually (I believe) VBL interrupts on the Mac occur when the electron
beam
>is moving from the bottom to the top of the screen on which the interrupt
was
>"installed".  That is, they ARE synch'd to the refresh rate of the
monitor
>you install the interrupt to (via SlotVInstall()).
>
>If you want to get every ounce of drawing time you can before the next
>retrace, use a VBL interrupt AND the Time Manager to wait for the beam to
>get just past the area of the screen you're drawing in ;-) (this may not
>buy you too much extra drawing time but it is neat).

I implemented a scheme based upon the above idea.  During initialization,
I used very simple timer and slotvbl tasks to measure, as accurately as
possible, the vbl rate for the chosen monitor.  Based upon this
information, I set a timer task going at 4 interrupts per slot interrupt.
I kept a very simple slot interrupt running just to make sure that my
timer interrupt didn't drift.  All blittling was done from the timer
interrupt, and was scheduled such that pixels where always blitted to the
screen in areas where the electron beam could not possibly be.

The program is a juggling pattern animator, and animates complicated
juggling patterns: 3-9 balls (for a two-handed juggler, hands not shown),
multiple throw heights, but always a "legal" juggling pattern, i.e. one a
perfectly skilled human juggler could perform without ball collisions, or
ever holding two balls in one hand.  On a 840av the result is stunning.
The program can show 24-bit, full 3D render balls at the full refresh rate
of the monitor (>60 fps), with absolutely no tearing or flicker.  Even at
better than 60 fps, it turns out that it is necessary to use motion blur
make the animation look right.  Otherwise, balls moving at high velocity
(just after a release, or just before a catch) look strobroscopic.

The problem with the above approach is that it's very hard to avoid cursor
droppings.  The basic trick of calling ShieldCursor doesn't seem to work
when ShieldCursor can get called multiple times per frame.   It was also
clear from testing on different platforms that the cursor dropping problem
varied across machines, from which I inferred that any hack to fix it
would possibly have to be different for each version of the ROM/System.
At this point, it finally sunk in that there were good reasons behind
Apple's warnings to not draw directly to the screen.

Of course, it may be that I could make the program work well if I did all
of the blitting from the vbl task, and didn't use the timer task, but when
I next get the urge to work on the program, I think I'll try to rewrite it
to not do any blitting at interrupt time.  It will probably make it easier
to take advantage of native PowerPC code anyway, since interrupt handling
requires a (relatively expensive) mode switch.

Jim Lloyd
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (kordon)
Date: 14 Apr 1995 22:47:35 GMT
Organization: Jet Propulsion Laboratory, Pasadena

In article <sherman1+-1204951646220001@128.147.45.101>
[e-mail] (Sherman Uitzetter) writes:

> you install the interrupt to (via SlotVInstall()).

Does anyone know how to get the slot number of the main monitor?

- mark -

+++++++++++++++++++++++++++

>From [e-mail] (Christopher David Burns)
Date: 17 Apr 1995 03:16:13 GMT
Organization: University of Auckland

[e-mail] (kordon) writes:

>In article <sherman1+-1204951646220001@128.147.45.101>
>[e-mail] (Sherman Uitzetter) writes:

>> you install the interrupt to (via SlotVInstall()).

>Does anyone know how to get the slot number of the main monitor?

TheGDevice = GetMainDevice();
TheDCtlHandle = GetDCtlEntry((**TheGDevice).gdRefNum);
TheAuxDCEPtr = (AuxDCE*)*TheDCtlHandle;
Slot = (*TheAuxDCEPtr).dCtlSlot;

Chris B
- ---------------------------------------------------------------------
NewZealand:AucklandUniversity:ComputerScience:HyperMediaUnit:ChrisBurns
Internet: [e-mail]
Phone:    [phone] x6194
Fax:      [phone]                         Async, therefore I am.
- ---------------------------------------------------------------------

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Sun, 16 Apr 1995 21:07:33 -0700
Organization: Skunkworks

In article <3mmu27$[e-mail]>, [e-mail]
(kordon) wrote:
>Does anyone know how to get the slot number of the main monitor?

>From DTS Tech Note HW 555 (Video Hardware Q&As):

void GetSlot(GDHandle gDev,short *slot)
{
  short    refNum;

  refNum = (**gDev).gdRefNum;   // video driver refNum for this GDevice
  *slot = (**(AuxDCEHandle)GetDCtlEntry(refNum)).dCtlSlot;
                   // slot in which this video card sits
}


Grobbins                [e-mail]

---------------------------

>From [e-mail] (James W. Walker)
Subject: Is Delay() defunct?
Date: Tue, 04 Apr 1995 19:38:55 -0500
Organization: Dept. of Mathematics, Univ. of South Carolina

Toolbox Assistant and the new Inside Mac do not seem to list Delay.  And
if I read OSUtils.h right, Delay is not implemented on the PowerPC.  So,
if Delay is defunct, how am I supposed to indicate a keyboard equivalent
of a button, like:

HiliteControl( my_button, inButton );
Delay( 8, &blah );
HiliteControl( my_button, 0 );

?
--
 Jim Walker

+++++++++++++++++++++++++++

>From [e-mail] (JoeLaff)
Date: 5 Apr 1995 00:15:27 -0400
Organization: America Online, Inc. (1-800-827-6364)

>>>>Toolbox Assistant and the new Inside Mac do not seem to list Delay.
And
if I read OSUtils.h right, Delay is not implemented on the PowerPC.  So,
if Delay is defunct, how am I supposed to indicate a keyboard equivalent
of a button, like:

HiliteControl( my_button, inButton );
Delay( 8, &blah );
HiliteControl( my_button, 0 );

?
--
 Jim Walker
<<<

Don't know if Delay is defunct.  I really doubt it, but you could use a
loop that uses some multiple of TimeDBRA. This global variable is supposed
to provide some indication of computer speed (although the latest IM I
read said that it was NOT a good indicator of speed because it could vary
too much).

You could also use a Time Manager Task, but this seems like a lot of
effort to keep your button highlited!!!

Joe
Joe <----
****  E N D    O F    L I N E  ****

+++++++++++++++++++++++++++

>From [e-mail] (The Bard)
Date: Wed, 05 Apr 1995 02:46:03 -0600
Organization: Bard 'O Matic Software

In article <[e-mail]>,
[e-mail] (James W. Walker) wrote:

> Toolbox Assistant and the new Inside Mac do not seem to list Delay.  And
> if I read OSUtils.h right, Delay is not implemented on the PowerPC.  So,
> if Delay is defunct, how am I supposed to indicate a keyboard equivalent
> of a button, like:
>
> HiliteControl( my_button, inButton );
> Delay( 8, &blah );
> HiliteControl( my_button, 0 );

I was wondering the same thing after finding it in the headers and not
seing it in Toolbox Assistant. But, I'm on a ppc and I can still call it.
It looks like Delay(x &i) where x and i are integers and x is delay in
system ticks and i contains the last system tick after delay exits...

I think this is correct... its working correctly in my ppc code :)

Wayde

+++++++++++++++++++++++++++

>From [e-mail] (Dan Lakeland)
Date: 5 Apr 95 19:29:57 GMT
Organization: Iowa State University, Ames, Iowa

In <3lt5gv$[e-mail]> [e-mail] (JoeLaff) writes:

>>>>>Toolbox Assistant and the new Inside Mac do not seem to list Delay.
>And
>if I read OSUtils.h right, Delay is not implemented on the PowerPC.  So,
>if Delay is defunct, how am I supposed to indicate a keyboard equivalent
>of a button, like:

>HiliteControl( my_button, inButton );
>Delay( 8, &blah );
>HiliteControl( my_button, 0 );

>?
>--
> Jim Walker
><<<

>Don't know if Delay is defunct.  I really doubt it, but you could use a
>loop that uses some multiple of TimeDBRA. This global variable is supposed
>to provide some indication of computer speed (although the latest IM I
>read said that it was NOT a good indicator of speed because it could vary
>too much).

>You could also use a Time Manager Task, but this seems like a lot of
>effort to keep your button highlited!!!

I don't know the granularity of Delay, but how about

while(TickCount() - prevTicks < TicksToWait)
        ;

--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
Macintosh Hacking, an art best learned w/ an axe...
The computer programmer's worst nightmare:
Unwittingly finding compiler bugs.

+++++++++++++++++++++++++++

>From [e-mail] (Larry Rosenstein)
Date: Wed, 05 Apr 1995 15:50:30 -0700
Organization: Taligent, Inc.

In article <3lt5gv$[e-mail]>, [e-mail] (JoeLaff) wrote:

>loop that uses some multiple of TimeDBRA. This global variable is supposed
>to provide some indication of computer speed (although the latest IM I

TechNote "PT 39 The DR Emulator" cautions against relying on DBRA for timing.

--
Larry Rosenstein
Taligent, Inc.

[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Nobukazu Toge)
Date: Thu, 6 Apr 1995 00:45:00 GMT
Organization: NETCOM On-line Communication Services (408 261-4700 guest)

James W. Walker ([e-mail]) wrote:
> Toolbox Assistant and the new Inside Mac do not seem to list Delay.  And
> if I read OSUtils.h right, Delay is not implemented on the PowerPC.  So,
> if Delay is defunct, how am I supposed to indicate a keyboard equivalent
> of a button, like:

> HiliteControl( my_button, inButton );
> Delay( 8, &blah );
> HiliteControl( my_button, 0 );

I agree that I don't see any documentation on _Delay in NIM OSUtils / TBE /
MoreTB and so on. On the other hand I see the _Delay trap being used
in several code examples shown in the NIM volumes! It looks like
an oversight by the NIM editors? The MTBA simply reflects what's
written and what's not in the current NIM, it appears to me

Regarding the definition of Delay, OSUtils.h reads

extern pascal void Delay(long numTicks, long *finalTicks)
 TWOWORDINLINE(0xA03B, 0x2280);

I don't know other dev systems, but with CodeWarrior C/PPC if one uses
the default precompiled header, ConditionalMacros.h is included. Now,
ConditionalMacros.h says if GENERATINGPOWERPC, then that means CFMSYSTEMCALLS,
and in that case TWOWORDINLINE means 'nothing'. So, in that case the linker
looks for the symbol Delay in whatever library included in the project.
For CW, Delay is defined in InterfaceLib, so as long as this lib is included,
the software links and runs fine.

--
Nobu Toge
     Internet: [e-mail]     AppleLink:      n.toge
     AOL     : ntoge                CompuServe:     76334,650
#include <StandardDisclaimers.h>

+++++++++++++++++++++++++++

>From [e-mail] (JoeLaff)
Date: 5 Apr 1995 23:16:48 -0400
Organization: America Online, Inc. (1-800-827-6364)


In article <3lt5gv$[e-mail]>, [e-mail] (JoeLaff)
wrote:

>loop that uses some multiple of TimeDBRA. This global variable is
supposed
>to provide some indication of computer speed (although the latest IM I

TechNote "PT 39 The DR Emulator" cautions against relying on DBRA for
timing.

--
Larry Rosenstein
Taligent, Inc.
<<<


I looked this up in NIM OS Utilities:
- ---
"The TimeDBRA value is calculated in ROM and is affected by the processing
method of the CPU (what's THAT mean?). Accordingly, for routines running
in RAM, it is not necessarily a good measure of how fast the computer is."
- ---

So this is not so great to use....

What would anyone suggest using to slow down say a CopyBits opperation to
time an animation so that it runs at the same speed on all machines?

(I can't use Ticks because a tick is too long.)

Thanks,
Joe <----
****  E N D    O F    L I N E  ****

+++++++++++++++++++++++++++

>From [e-mail] (LearnTV)
Date: 6 Apr 1995 13:10:30 -0400
Organization: America Online, Inc. (1-800-827-6364)

>What would anyone suggest using to slow down say a CopyBits opperation to
>time an animation so that it runs at the same speed on all machines?
>
>(I can't use Ticks because a tick is too long.)

Check out the Time Manager.  Microseconds and Milliseconds.

Greg Bolsinga
Learn Television

+++++++++++++++++++++++++++

>From [e-mail] (Grobbins)
Date: Sun, 09 Apr 1995 13:11:28 -0700
Organization: Skunkworks

In article <[e-mail]>, [e-mail]
(Dan Lakeland) wrote:
>I don't know the granularity of Delay, but how about
>while(TickCount() - prevTicks < TicksToWait)
>        ;

In spite of the Inside Mac documentation lapse, calling Delay is
preferable to looping on TickCount.  Delay tells the system that the
current process doesn't need time right now; this potentially allows the
OS to use the free cycles for something else.  Today, the distinction is
academic since the Mac doesn't do anything during Delay calls, but in the
future this may change.

Grobbins                               [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Jump Long)
Date: 16 Apr 1995 23:17:30 -0400
Organization: America Online, Inc. (1-800-827-6364)

>In article <[e-mail]>, [e-mail]
>(Dan Lakeland) wrote:
>>I don't know the granularity of Delay, but how about
>>while(TickCount() - prevTicks < TicksToWait)
>>        ;
>
>In spite of the Inside Mac documentation lapse, calling Delay is
>preferable to looping on TickCount.  Delay tells the system that the
>current process doesn't need time right now; this potentially allows the
>OS to use the free cycles for something else.  Today, the distinction is
>academic since the Mac doesn't do anything during Delay calls, but in the
>future this may change.

Another thing to note about Delay... don't call it at interrupt time. The
first thing it does is fully enable interrupts which probably wouldn't be
a good thing to do at interrupt time.

- Jim

+++++++++++++++++++++++++++

>From [e-mail] (ALTURA)
Date: 17 Apr 1995 15:20:49 -0400
Organization: America Online, Inc. (1-800-827-6364)

> Is Delay() defunct?

DeNo

---------------------------

>From [e-mail] (Thomas Reed)
Subject: Looking for advice on a jGNEFilter...
Date: Tue, 11 Apr 1995 12:08:56 -0500
Organization: Washington University

I'm getting ready to try my hand at implementing a jGNEFilter, but I've
got some technical questions.  This filter will be for an application, not
an extension, so there are some problems I can see that I haven't found a
really elegant answer to yet.  Hopefully, someone out there can give me
some advice.

The problem is that the filter has to be able to compensate for the fact
that the application might quit, or even worse, crash.  In which case, if
the filter didn't compensate, it would hose everything when it tried to
call a function in the app.

Now, there are several solutions I can see, but I'm not satisfied with any
of them.  First, I could have the filter not call any functions in my app,
and communicate with the app by using AppleEvents.  But, it seems like
this could flood the machine in AppleEvents, since I'd be potentially
interested in seeing the data for each keystroke.

Second, I thought about having the filter installed from an INIT, so it
would always be there.  But, the problem arises of how it can tell that my
app is running, how my app finds the filter to change the filter's stored
data (stuff like the app's A5, handler in the app to call, etc.), how the
filter figures out that the app has quit or crashed, etc.

I considered having the app install a filter that checks the process list
before calling a handler in my app.  This would solve the problems with
the filter not hosing when the app quits or crashes (quitting actually
wouldn't be a problem, as I could just change some value in the filter
before quitting).

This still leaves a question open, though.  Do I install the filter from
the app just once, and somehow (maybe via an AppleEvent) get the address
of the filter back on the second launch.  But, that's flawed, because
there's not a way to determine when the app starts up that the filter is
installed.  So I considered having the filter disable itself when the app
isn't running, and having the app install a second filter on the next
launch.  But, seems like this could fill up the System heap.

I don't know what to do!  Please help!  (Sorry for the length...)

-Thomas

=====================================================
Thomas Reed                     Washington University
[e-mail]               Medical School
[e-mail]            Saint Louis, MO
- ---------------------------------------------------
Clothes make the man.  Naked people have little or no
influence on society.  -- Mark Twain
=====================================================

Opinions posted are not the opinions of Wash. U.

+++++++++++++++++++++++++++

>From Eric Bowman <[e-mail]>
Date: 14 Apr 1995 01:20:00 GMT
Organization: Esoterotica Research

In article <reed-1104951208560001@thomas_mac.wustl.edu> Thomas Reed,
[e-mail] writes:
>I'm getting ready to try my hand at implementing a jGNEFilter, but I've
>got some technical questions.  This filter will be for an application, not
>an extension, so there are some problems I can see that I haven't found a
>really elegant answer to yet.  Hopefully, someone out there can give me
>some advice.
>The problem is that the filter has to be able to compensate for the fact
>that the application might quit, or even worse, crash.  In which case, if
>the filter didn't compensate, it would hose everything when it tried to
>call a function in the app.

I'm preparing to release a Component Manager component called "GNE
Manager"
which handles much of the gnarliness of installing filters.  The component
is registered at startup, and patches jGNEFilter at that time.

Client applications open an instance of the component, and pass it a
UPP to their filter function.  The component takes care of setting up
A5 and restores whatever zone was the current zone when the component was
opened. If your app shuts down unexpectedly, the Component Manager
closes any component instances that lived in your app's heap, which
prevents calls to never-never land.  At least in principle; I haven't
tested this too thoroughly yet.

It's super cool and makes patching jGNEFilter a breeze,, but I think it's
still buggy, and it's not documented at all, so I was going to work on
it a bit more before releasing it.  It borrows heavily from Pete
Resnick's
"jGNE Helper" code that's floating around.  At least, I *think* Pete
wrote
it, I'm sure he'll tell me if I'm wrong.

If you want to help me debug it, I'll gladly send it to you now.

Now that I'm unemployed, I have lots of time on my hands. :)

cheers,
bobo
--
[e-mail]
[e-mail]
Esoterotica Research
If we do not expect the unexpected, we will never find it. - Heraclitus

+++++++++++++++++++++++++++

>From [e-mail] (Pete Gontier)
Date: Wed, 19 Apr 1995 17:11:33 -0700
Organization: cellular

In article <3mkik0$[e-mail]>,
Eric Bowman <[e-mail]> wrote:

> (My jGNEFilter API component) borrows heavily from Pete Resnick's
> "jGNE Helper" code that's floating around.  At least, I *think* Pete
> wrote it, I'm sure he'll tell me if I'm wrong.

Wrong Pete, but I forgive you. :-)

______________________________________________________________________________
 Pete Gontier -- MacZealotry, Ink. -- [e-mail]

 "It's great to work for a company that lets you build good software
  and doesn't give you any shit..."
             -- John McEnerney, Metrowerks PowerPC Product Architect

---------------------------

>From [e-mail] (Demos)
Subject: NEW DEVELOPMENT ARCHIVE at AMUG!
Date: Sun, 16 Apr 1995 04:22:29 -0600
Organization: University of Utah

Hi everyone,
I am glad to announce that 4/16/95 Arizona Macintosh User Group is
supporting development section! I volunteered to maintain the archive. I
managed to mirror alt.sources.mac and other places I knew. The structure
is pretty simple so far:

ftp.amug.org /pub/demos/development (hopefully we will move to /pub/development)
the pub/demos/development directory contains:
incoming/         (where you can upload new code examples)
alt.sources.mac/  (mirror of alt.sources.mac)
personal/         (code I have written)
requests/         (you can request some code here if you want)
and I can add another sections if you request.
I belive AMUG will soon become a major macintosh development supporter, as
well as the major macintosh contributer to the macintosh community.

If everything goes well, AMUG will press a CD with freely distributed
source code.

I personally wish to contribute all the code I have written that can be
distributed. My personal interests involve real time animation and 3d
graphics as well as communications; I am interested in writing more
DEMO(s) for Macintosh.

Please let me know if you like that idea and if you own a little
collection of the sample codes, I am willing to mirror your site.

Thank you!

Regards,
Demos.

_____________________________________________________________________
Demos <[e-mail]>   |  IRC: #macdev  |  ftp://amug.org/pub/demos

---------------------------

>From [e-mail] (Olivier Baur)
Subject: Problem drawing PICT with QT (-8976!?)
Date: 14 Apr 1995 18:25:31 GMT
Organization: Georgia Institute of Technology

Hi there !

I've got a strange problem when I try drawing a PICT file containing a
JPEG compressed pixmap (PICT opcode $8200) into a G-World, using the QT
function DrawPictureFile:
QuickTime will return an error code -8976 if the GWorld is smaller than
the destination rectangle I'm trying to draw to (I'm drawing the pict
file band by band, because it can be huge -- 10Mb+ -- and the routine
should be able to run with only little memory avaible).

Now, the big problem is that error -8976 is NOT referenced in
IM-QuickTime (I've found that error -8976 is related to some printing
problem!)...
What's more, most of the time, DrawPictureFile will actually draw the
pict into the gworld AND return that error code. I've tried ignoring
error -8976, but the problem is that it happens only "most of the
time", and sometimes DrawPictureFile won't do nothing (especially for
the last bands of the pict).

HELP !!!
Any help will be welcome !!!

Olivier Baur

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sat, 15 Apr 1995 16:26:19 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <3mmemr$[e-mail]>, [e-mail]
(Olivier Baur) wrote:
> Now, the big problem is that error -8976 is NOT referenced in
> IM-QuickTime (I've found that error -8976 is related to some printing
> problem!)...
> What's more, most of the time, DrawPictureFile will actually draw the
> pict into the gworld AND return that error code. I've tried ignoring
> error -8976, but the problem is that it happens only "most of the
> time", and sometimes DrawPictureFile won't do nothing (especially for
> the last bands of the pict).

Try to install the Apple MM Tuner 2.0.1 to see what happens! Yes, just
ignore that error for the time being.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From [e-mail] (Rolf-Stephan Badura)
Subject: QuickTime & MPEG-Streams?
Date: Tue, 11 Apr 1995 08:19:24 +0200
Organization: Technical University of Berlin, Germany

Hi,

I must implement a window with a MPEG stream from the net. Hardware
(Mason) is in my box. I like to use QuickTime, maybe with a special Media
Data Handler. But how can I tell QuickTime to use this MPEG data (I should
not copy the data to the local machine!).

Thanx, BuddY+E

<URL:http://www.cs.tu-berlin.de/~buddy>

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Thu, 13 Apr 1995 22:09:09 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>,
[e-mail] (Rolf-Stephan Badura) wrote:

> Hi,
>
> I must implement a window with a MPEG stream from the net. Hardware
> (Mason) is in my box. I like to use QuickTime, maybe with a special Media
> Data Handler. But how can I tell QuickTime to use this MPEG data (I should
> not copy the data to the local machine!).

Phew, this is a long story. To tell it all shortly, check out the QT
Conferencing APIs when they will ship some time this spring. QTC has a new
architecture for streamed data, MPEG and such, and you should write so
called stream players to handle the MPEG streams. Either you will write a
specific system stream player that does it all, or separate audio and/or
video stream players for decoding these parts.

Writing a data handler for MPEG is not recommended, this because the QT
architecture is not really designed for this purpose. In other words
whatever movie toolbox support we add it will be included as part of the
stream player architecture, first in QTC, and then later in QT 2.x
versions.

Now some of you wonder how we handle MPEG today, we read the data in from
the file using our HFS data handler, have a specific MPEG media handler,
and this one redirects the decoding stream to hardware. This is now the
Wired box works just now (Mason). But if you want to read data over the
network (video servers and such), you need to implement a specific data
handler that will push the data up to the MPEG media handler that takes
care of the rest.

--Kent

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From [e-mail] (Anthony Berno)
Subject: Speeding up NewPtr
Date: 29 Mar 1995 19:13:14 GMT
Organization: Stanford DNA Sequence and Technology Center


My app (both 68K and PPC) is spending a lot of time creating many
(thousands) of small (~500 byte) chunks of memory using NewPtr.
Unfortunately, this is taking a fair bit of time. Is there any way to
speed up NewPtr for this type of memory usage, short of writing my own
memory manager? Thanks.

-Anthony

+++++++++++++++++++++++++++

>From "Andrew C. Plotkin" <[e-mail]>
Date: Wed, 29 Mar 1995 17:17:11 -0500
Organization: Information Technology Center, Carnegie Mellon, Pittsburgh, PA

Excerpts from netnews.comp.sys.mac.programmer.misc: 29-Mar-95 Speeding
up NewPtr Anthony [e-mail] (306)

> My app (both 68K and PPC) is spending a lot of time creating many
> (thousands) of small (~500 byte) chunks of memory using NewPtr.
> Unfortunately, this is taking a fair bit of time. Is there any way to
> speed up NewPtr for this type of memory usage, short of writing my own
> memory manager?

No.

Fortunately, writing your own memory manager is pretty easy, especially
if all the chunks are the same size. NewPtr a big chunk (the size of 200
small chunks, say) and divvy it up according to some clever scheme. The
details depend on whether you want to be able to dispose them as
quickly, or at all.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."

+++++++++++++++++++++++++++

>From Nathaniel P Woods <[e-mail]>
Date: Wed, 29 Mar 1995 19:59:59 -0500
Organization: Freshman, Electrical and Computer Engineering, Carnegie Mellon, Pittsburgh, PA

>My app (both 68K and PPC) is spending a lot of time creating many
>(thousands) of small (~500 byte) chunks of memory using NewPtr.
>Unfortunately, this is taking a fair bit of time. Is there any way to
>speed up NewPtr for this type of memory usage, short of writing my own
>memory manager? Thanks.

My advice to you would be to make your own memory management that
allocates large blocks with NewPtr() and then parcels off chunks of
these blocks off.

Nathaniel

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Fri, 31 Mar 1995 18:25:52 GMT
Organization: Apple Computer, Inc.

In article <[e-mail]>, Nathaniel P Woods
<[e-mail]> wrote:

> My advice to you would be to make your own memory management that
> allocates large blocks with NewPtr() and then parcels off chunks of
> these blocks off.

...which is exactly what the malloc and operator new libraries supplied
with C and C++ compilers do. They're typically much faster than NewPtr.


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

+++++++++++++++++++++++++++

>From [e-mail] (Magao)
Date: 4 Apr 1995 15:40:48 +1000
Organization: University of Wollongong, NSW, Australia.

In <[e-mail]> [e-mail] (Anthony Berno) writes:


>My app (both 68K and PPC) is spending a lot of time creating many
>(thousands) of small (~500 byte) chunks of memory using NewPtr.
>Unfortunately, this is taking a fair bit of time. Is there any way to
>speed up NewPtr for this type of memory usage, short of writing my own
>memory manager? Thanks.

   Well, you can do it by *kinda* writing your own memory manager ... it's
especially easy if all your chunks are the same size (which is what I'm
going to do here).

   Allocate one *big* chunk of memory (preferably large enough to hold
them maximum number of items, otherwise you'll have to allocate another
chunk later and it starts getting messy).

   Keep track of the address of the *next* chunk to be used (i.e. the
address of the last chunk + the chunk size (in bytes)). When you first
allocate the big chunk you will of course set the next address to the
start of the chunk.

   Whenever you need a new chunk simply assign the address of the next chunk
to the pointer and increment the next chunk pointer the correct number of
bytes.

   Note : This model assumes that
                all chunks are the same size
                enough memory is preallocated to hold all chunks
                you either never want to free memory (except when you've
                finished with the whole lot) OR
                you don't care that freed memory will be unusable.

   If you want any other bells and whistles then things can start to get
a bit messy (you've got to actually make some design decisions). One of
these design decisions should be "Should I implement this myself, or
should I go with malloc/free which is already doing this ?" (I don't
*know* of any implementation of malloc/free which doesn't preallocate
a big chunk of memory - but there may be some out there). Of course,
this is assuming you're using C - if you're using Pascal I don't know
how new/dispose (or new/delete for C++) are handled. I guess you're using
Codewarrior (oops ... I've completely forgotten which newsgroup I'm in ...)
so you could ask Metrowerks what method they use.


                                       _/_/_/_/
   __|  __|        _/_|     _/_/_/      _/_|     _/_/_/
  _/_| _/_|      _/  _|   _/          _/  _|   _/    _/
 -/ _|_/ _|    _/_/_/_|  _/ _/_/_/  _/_/_/_|  _/    _/
_/  __/  _|  _/      _|  _/_/_/   _/      _|  _/_/_/

   Tim Delaney (TCD Software)     [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Ned Mantei)
Date: Tue, 04 Apr 1995 15:35:42 +0200
Organization: Swiss Federal Institute of Technology (ETHZ)

In article <[e-mail]>,
[e-mail] (Anthony Berno) wrote:

> My app (both 68K and PPC) is spending a lot of time creating many
> (thousands) of small (~500 byte) chunks of memory using NewPtr.
> Unfortunately, this is taking a fair bit of time. Is there any way to
> speed up NewPtr for this type of memory usage, short of writing my own
> memory manager? Thanks.

Perhaps use malloc() from the ANSI library? This asks the system for
memory in larger chunks and hands it out to you. NewPtr is only called if
you use up a large chunk. I seem to remember that this should be faster
for a case like yours.

--
Ned Mantei
Neurobiology, Swiss Federal Institute of Technology
CH-8093 Zurich, Switzerland
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Henri Schueler)
Date: Tue, 04 Apr 1995 11:51:22 -0500
Organization: H&h Software

In <[e-mail]>
[e-mail] (Anthony Berno) writes:


>My app (both 68K and PPC) is spending a lot of time creating many
>(thousands) of small (~500 byte) chunks of memory using NewPtr.
>Unfortunately, this is taking a fair bit of time. Is there any way to
>speed up NewPtr for this type of memory usage, short of writing my own
>memory manager? Thanks.

Remember that NewPtr causes memory compaction. It does this because it
wants to avoid problems that are caused by fragmentation from Ptrs.

When I first started programming on the Mac, I assumed that HLocked
Handles would be more expensive than Ptrs, so when either would do, I used
Ptrs. This was a mistake. Its much better to do:
    a = NewHandle (b);
    HLock(a);
    c = *a;
..do some work using c, for a short term
    DisposeHandle(a);

than to use NewPtr/DisposePtr.

- -------------------------------------------------------------------
J.Henri Schueler              H&h Software             1-416-698-9075
[e-mail] (preferred)    (alternate) [e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Fabrizio Oddone)
Date: Mon, 10 Apr 1995 12:59:44 +0200
Organization: Computer Science Faculty, Torino
In article <[e-mail]>, [e-mail] (Gregory
Jorgensen) wrote:

> Use the standard library functions malloc() and free(), which do exactly
> what you want. With Symantec C malloc's crossover size (the size of the
> largest block it will allocate in its own pools before it goes to NewPtr)
> is 15,000 bytes. In Code Warrior the crossover is 32K. You can change this
> magic number and recompile the Symantec libraries.
>
> Don't reinvent the wheel--it's been done.

In theory...

It just happens that for REAL usage, both Symantec and CodeWarrior (4.5,
never tried the newer ones) are broken.

When optimizing GW/Ada Mac, I had to rewrite malloc/free/realloc from
scratch in order to let them work.

Nice side effects:
I can choose the crossover size;
I can use temporary memory by simply changing a #define.

It seems that the _NewPtr inefficiency is an FAQ...

Anybody wants the source?

--
 Fabrizio Oddone <[e-mail]>
http://www.di.unito.it/pub/WWW/www_student/apple/FabrizioOddone/

+++++++++++++++++++++++++++

>From [e-mail] (Glenn L. Austin)
Date: Wed, 12 Apr 1995 11:50:11 -0700
Organization: Symantec Corporation

In article <[e-mail]>,
[e-mail] (Fabrizio Oddone) wrote:


> In article <[e-mail]>, [e-mail] (Gregory
> Jorgensen) wrote:
> > Use the standard library functions malloc() and free(), which do exactly
> > what you want. With Symantec C malloc's crossover size (the size of the
> > largest block it will allocate in its own pools before it goes to NewPtr)
> > is 15,000 bytes. In Code Warrior the crossover is 32K. You can change this
> > magic number and recompile the Symantec libraries.
> > Don't reinvent the wheel--it's been done.
> In theory...
> It just happens that for REAL usage, both Symantec and CodeWarrior (4.5,
> never tried the newer ones) are broken.
> When optimizing GW/Ada Mac, I had to rewrite malloc/free/realloc from
> scratch in order to let them work.
> Nice side effects:
> I can choose the crossover size;
> I can use temporary memory by simply changing a #define.


At Symantec, we've already rewritten malloc/free/realloc to better deal
with memory on the Macintosh.  The new version does more checking (which
you can turn off) and is configurable from code (by changing global
variables).  However, since we didn't get as much time to check it as we
wanted, the old one is the default one shipped with 8.0, although the
alternate malloc is in the Goodies folder.

//
// Glenn L. Austin, Symantec Macintosh Developer Tools Support
// mailto:[e-mail]
//

+++++++++++++++++++++++++++

>From [e-mail] (Jens Alfke)
Date: Thu, 13 Apr 1995 15:05:19 GMT
Organization: Apple Computer, Inc.

OpenDoc has its own memory manager that is optimized for nonrelocatable
malloc-style allocation. It's based on the memory manager written for
MacApp 3.1 and Bedrock. The memory manager is built as a separate shared
library called (duh) "Memory Manager". It's in the same folder as all the
other OpenDoc libraries (in the Extensions folder.) There's full
documentation of its API in the Technical Notes folder on the CD.
This library has no dependencies on the rest of OpenDoc. You can use it
from your own app and the rest of OpenDoc will not load. The memory
manager is only about 16k in size (about 30k in the debug build.)
It's got a lot of nice debugging features too, including heap checking.
Drawbacks: On 68k it requires the use of CFM, i.e. it can only be called
from new-runtime apps. There are no plans to ship it separately from the
rest of OpenDoc, and you probably can't redistribute it yourself.
Otherwise, have fun with it...


Jens Alfke_________OpenDoc [e-mail]
                                           OpenDoc info: FTP to CILabs.org

         Visit Scenic Flood Control Dam No. 3.

---------------------------

>From [e-mail] (Reevan McKay)
Subject: Where is the QTv2.0 header file?
Date: Sun, 9 Apr 1995 21:46:50 GMT
Organization: Carleton University



Does anyone have any idea where we are supposed to get header files for
Quicktime 2.0?  Can we get them from info.apple.com?  Or do we need to buy
a new compiler? >:(  Failing that, does anyone have a QTv2.0 header file
that they can send me (THINK C++ v7.04)?  If that's legal, of course...
I especially need the QT Musical Architecture stuff.  Any help would be
real handy. :)

Send email to [e-mail]

Thanx.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Sun, 09 Apr 1995 22:01:08 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail]
(Reevan McKay) wrote:

> Does anyone have any idea where we are supposed to get header files for
> Quicktime 2.0?  Can we get them from info.apple.com?  Or do we need to buy
> a new compiler? >:(  Failing that, does anyone have a QTv2.0 header file
> that they can send me (THINK C++ v7.04)?  If that's legal, of course...
> I especially need the QT Musical Architecture stuff.  Any help would be
> real handy. :)

The QT header files are part of the Universal header files, 2.0a3 is the
latest version, even if the MW 5.5 upgrade had a couple of newer header
files. Available from:
ETO CDs
Symantec releases
MW releases
PowerPC tool releases
QT 2.0 SDK CD (worth getting as it's the reference CD for all the material
related to QT programming today)
OS SDK CDs (worth getting as these are the complete sets of APIs and
libraries for Mac application development)
ftp.info.apple.com, url:
ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Tool_Chest/Interfaces/Universal_Interfaces/
(found that one after five minutes  of browsing)

Cheers, Kent
PS: I tested about 80% of the QT SDK CD samples using 2.0a3.

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

+++++++++++++++++++++++++++

>From [e-mail] (Kent Sandvik)
Date: Mon, 17 Apr 1995 23:31:36 -0800
Organization: Apple Computer, Inc. Developer Technical Support

In article <[e-mail]>, [e-mail]
(Reevan McKay) wrote:

> Does anyone have any idea where we are supposed to get header files for
> Quicktime 2.0?  Can we get them from info.apple.com?  Or do we need to buy
> a new compiler? >:(  Failing that, does anyone have a QTv2.0 header file
> that they can send me (THINK C++ v7.04)?  If that's legal, of course...
> I especially need the QT Musical Architecture stuff.  Any help would be
> real handy. :)

Universal headers, URL:
ftp://ftp.info.apple.com/Apple.Support.Area/Developer_Services/Tool_Chest/Interfaces/Universal_Interfaces/

QuickTime 2.0 documentation, Acrobat Format:
ftp://ftp.info.apple.com/dts/quicktime/QT_MAC.PDF.hqx

This should go to the developer FAQ...

--Kent/DTS

--
Kent Sandvik   [e-mail]                  Working with Multimedia stuff...
Apple Developer Technical Support.                                     Private activities on Internet.

---------------------------

>From [e-mail] (Dan Lakeland)
Subject: [MINI FAQ] Programming with MacTCP
Date: 16 Apr 95 17:15:54 GMT
Organization: Iowa State University, Ames, Iowa

Some info on using TCP on the mac:

(note none of this is guaranteed to apply to OpenTransport)

FIRST: Use the Universal Headers. The file MacTCP.h includes all the
info in the older headers in ONE FILE. Get these from ftp.info.apple.com
if you don't have them (MW codewarrior comes with them).

SECOND: there is a bug in the Universal Headers (the version I have at
least) which doesn't set the struct alignment to 68k unless you're
compiling on a PPC. Therefore, you should either edit a copy of the
headers to do this, or DON'T USE 68k-4byte alignment in your project....

ALSO:
Watch out for MacTCP.p because it uses 'array of byte' where it
really really really wants to be 'packed array of byte'.

The MacTCP interfaces have a long long tradition of being screwed up :-)

THIRD: GET the MacTCP DK from ftp://seeding.apple.com. And
ftp://ftp.info.apple.com it describes how to use the TCP driver.

FOURTH: An overview of the TCP Driver:

I have been told that this section is less useful, as it contaings an
overview of information found in the TCPDK which is so quick that it
might confuse newbies, and so sparse that people who know driver
programming don't need to read it. But I think it's useful to get an
overview of the types of things you can do with the TCP driver. It is
NOT a replacement for the TCPDK which is available at
ftp://seeding.apple.com. And ftp://ftp.info.apple.com

Create a Stream with a PBControl call: This call allocates all the
information and control structures and buffers etc, and associates them
with a stream ID which is returned to you. You also may not touch the
internals of the stream (esp. the buffers you gave to TCP) until you
have released it.

WARNING: You absolutely must release any stream you successfully create.
Failure to do this will cost death and destruction that you don't want to
be responsible for. In order to facilitate debugging. There is an init
Zap_TCP which is available at ftp.info.apple.com which releases streams
that are left over when your app crashes. Get it, but don't rely on it :-)

Find an Address (you can use the Domain Name Resolver to translate from
either a "name.name.name" type string or "number.number.number.number"
type string into 6 bytes which completely describe a location on the
internet. An ADDRESS: is 4 bytes. A port is 2 bytes (hence 6 bytes)

The DNR does not deal with ports.  The DNR will (sometimes, if you're
really nice to it :-) turn names in to 4 byte IP addresses.

ports do however come semi-magically from opening a stream. When you
attempt to connect to an address you specify a port. When you wait for
a connection you recieve the port that the other person attempted to
connect to.

WARNING: There is no way to abort a name lookup in progress - you must
wait til it completes or timesout.  Failure to do so will (you know the
rest... :-)

Which brings up a good point. Set your timeouts to be valid :-). They're
usually a byte which gives the number of seconds to wait until failure.

Open a Connection with a PBControl call:
Use the stream allocated above and the address and port found above...

Send Data via PBControl calls:
Pass a send data record, it is described in the DK, but it looks
approximately like:

short
Ptr
short
Ptr
....
short
Ptr
short 0 // end of data is signified by 2 zero bytes

Each Ptr points to some data, and each short describes how long the data
is. The TCP Driver will send all the data (eventually)

Recieve Data via PBControl calls:
Either have TCP copy data into your buffer, or give you a pointer to
it's own internal buffer so you can read from it.... In the latter case
you must also tell TCP When you're done..

Close/Abort connection via PBControl:

WARNING: Don't call Close twice.
NOTE: There is generally no need to call abort, since releasing a stream
will abort the connection.
NOTE: Giving a close command does not close a stream.  All it means is
that you will not send any more data.  The stream remains open until both
sides have closed it.  Releasing a stream before it is closed gracefully
(some time after both parties have closed it) may result in data loss.

Also there are a variety of things that might cause a stream to abort
automatically, like for example timeouts. You can usually pass TCP a
function to call when something anomalous happens, if this function is
set correctly then you handle the anomaly yourself. Otherwise the stream
aborts, and returns some sort of error to you. So don't go sending data
across an aborted connection.

Deallocate stream when done (you guessed it PBControl):
When you do this, you get all that buffer memory back. You can reuse it,
or dispose of it, but you can't touch it until after you've disposed the
stream.

Hope this has helped someone.

Many thanks to Peter Lewis, the TCP guru for suggestions and additions.

This FAQ is copyright 1995 by Daniel Lakeland. It is freely
distributable under the condition that any modifications be sent to me
for inclusion into the general FAQ. Suggestions for additional info
should be sent to me. [e-mail]. I do not guarantee the
accuracy of this information, nor do I make any guarantees of anything
(this is the cover my butt portion of the document).


--
Daniel Lakeland: Macintosh Hacker, Mathematics Major, NRA Member.
Macintosh Hacking, an art best learned w/ an axe...
The computer programmer's worst nightmare:
Unwittingly finding compiler bugs.

---------------------------

>From [e-mail] (Michael K. Neylon)
Subject: [Q] Temporary Files
Date: 12 Apr 1995 23:33:44 GMT
Organization: University of Michigan Engineering, Ann Arbor

My app will create a file with both a resource and a data fork, and I
would like to keep the non saved version in a temporary file because
of the resource fork.  However, I don't see any info in the HIG or
IM:Files that mentions where temp files should be stored.  Where
are temporary files usually stored, and is there a good way to name
them.  Any info is appriciated.

--
  Michael K. Neylon, Graduate Student           | "It was a dark and stormy
  Dept. of ChE, Univ. of Michigan               |   night...I had just
  [e-mail]                       |   taken a creative
  http://www.engin.umich.edu/labs/mel/mneylon/  |   writing course..." MST3K

+++++++++++++++++++++++++++

>From [e-mail] (Marshall Clow)
Date: Wed, 12 Apr 1995 22:45:11 -0700
Organization: Aladdin Systems

In article <3mho0o$[e-mail]>, [e-mail]
(Michael K. Neylon) wrote:

> My app will create a file with both a resource and a data fork, and I
> would like to keep the non saved version in a temporary file because
> of the resource fork.  However, I don't see any info in the HIG or
> IM:Files that mentions where temp files should be stored.  Where
> are temporary files usually stored, and is there a good way to name
> them.  Any info is appriciated.
>

    Temporary files should be created in the "Temporary Items" folder on
the same volume as the data file, unless the data file is on a server
which you don't have write access to, in which case it should be created
in the "Temporary Items" folder on the boot volume. Whew!

    The "Temporary Items" folder can be found/created with FindFolder. See
the header file "Folders.h". Also NIM:Toolbox Essentials, pp 7-43 and
7-54.

-- Marshall

--
Marshall Clow
Aladdin Systems
[e-mail]

+++++++++++++++++++++++++++

>From [e-mail] (Chuck (Chuck Bo Buck...) McMath)
Date: Fri, 14 Apr 1995 14:23:59 GMT
Organization: Reed Technology and Information Services, Inc.

Michael K. Neylon ([e-mail]) wrote:
: My app will create a file with both a resource and a data fork, and I
: would like to keep the non saved version in a temporary file because
: of the resource fork.  However, I don't see any info in the HIG or
: IM:Files that mentions where temp files should be stored.  Where
: are temporary files usually stored, and is there a good way to name
: them.  Any info is appriciated.

   Well, if you can use FindFolder, there is a parameter for 'folderType'
called kTemporaryFolderType which identifies where you can store temp
files.  Think Reference says it's on the root of the boot volume, in an
invisible folder (and I've used temp files, and agree with them!).

As to what to name them, my strategy was to derive a name based
upon the stuff I was storing on the disk.  That way, when I went to
create a temp file, I could look in the temp file folder and see if that
file had already been stuck there.  And if it had, I didn't have to
store it there again.  But it that approach doesn't apply, you could
call TickCount() or something like that, convert the number to a string
and use that.

Remember, temp files should only be around while your app is running,
so you should close and delete them when the app quits (or whenver you
are sure you're thru with the file).  And if you *really* wanna do it
right, you'll check the temp directory when your app starts up to see
if there is any garbage left over from a prior session in which your
app blew up and didn't get a chance to clean up after itself (don't
ask how I came up with that rule...).

Good luck!

chuck

+---------------------------------------------------------------------------+
|      Chuck McMath * Reed Technology and Information Services, Inc.        |
|       20251 Century Blvd * Germantown, MD 20874 * [e-mail]           |
|"Hey batter, hey batter, swing!" (Anon) * Jeans by Jordache;Body by Fritos |
+---------------------------------------------------------------------------+

---------------------------

>From [e-mail] (Jan Melander)
Subject: [Q] Where is the stack?
Date: Mon, 10 Apr 1995 15:09:08 GMT
Organization: WM-Data

Hi,

In our project we have implemented a trace for memory protection by
capsule memory operations (alloc, free, memcpy, strncpy....) and do a
range check when used. I'd like to be able to check if the operation on
global and local variables is at least within the stack frame, to do that
I need to know where the stack begins and how large it is.
I know that certain registers contatins the pointers but I need to access
them from C and I like to make it work on both 68K and PPC machines.

Does anybody got any good ideas?

Cheers,

--
- -------------------------------------------------------------
        Jan Melander
        WM-Data
        [e-mail]
- -------------------------------------------------------------
Q:Why didn't Intel name their CPU 586 instead of Pentium?
A:When they added 100 to 486 the readout said 585.9999999999765,
  and it didn't fit on the chip.

+++++++++++++++++++++++++++

>From [e-mail] (Dan Wright)
Date: Thu, 13 Apr 1995 20:55:34 -0700
Organization: Northwest Nexus Inc.

In article <[e-mail]>,
[e-mail] (Jan Melander) wrote:

>Hi,
>
>In our project we have implemented a trace for memory protection by
>capsule memory operations (alloc, free, memcpy, strncpy....) and do a
>range check when used. I'd like to be able to check if the operation on
>global and local variables is at least within the stack frame, to do that
>I need to know where the stack begins and how large it is.
>I know that certain registers contatins the pointers but I need to access
>them from C and I like to make it work on both 68K and PPC machines.
>
>Does anybody got any good ideas?
>

You can do this with inline assembly, but it isn't necessary, and besides
you want
it to work on PPC too... this will do the trick:

/* StackData - return TRUE if pthing is on the stack somewhere */
Boolean StackData(void *pthing)
{
   char topOfStack;

   return ((Ptr)pthing > &topOfStack && pthing < LMGetCurStackBase());
}

Taking the address of a local forces the compiler to store it on the stack
(not at the
absolute top, but close enough).

You can also calculate the top of the stack as:
(LMGetCurStackBase() - StackSize())

Incidentally, global variables aren't on the stack. For 68k apps, pthing
would be
greater than LMGetCurStackBase() for globals; in ppc apps, they're at the bottom
of your heap (subject to change in future versions of system software of
course).

On ppc, here's one way to determine whether pthing points to a global:

#ifdef powerc

Ptr gPtrLow; // global

// VERY early in your initialization, do this:
void main(void)
{
   gPtrLow = NewPtr(1);
   MaxApplZone();
}

// then...
Boolean GlobalData(void *pthing)
{
    Ptr *ptv = (Ptr *)GlobalData;
    Ptr ptoc = ptv[1];

    return ((Ptr)pthing > ptoc && (Ptr)pthing < gPtrLow));
}
#endif // powerc

Boy, there's a whole trivia contest just lurking in this sample. :-)

- Dan

--
Dan Wright
[e-mail]

---------------------------

End of C.S.M.P. Digest
**********************